Current software system testing approaches adopted by many organizations require each organization to devise its own tests. Thus, each organization needs to learn which transactions, business processes, and/or modules should be tested on its system. Gaining this knowledge may require much effort and experience. Since the software systems are often so large and complex, containing thousands of transactions and business processes that may be tested, it is often quite difficult to determine which transactions and business processes are important for the system, which are likely to be utilized, and in some cases, it is even difficult to get a comprehensive view of which transactions can be run on the system. Thus, for many organizations testing is a suboptimal iterative process, relying trial-and-error experimentation and gradual acquiring of domain knowledge.
Despite the variety in software systems that can be found, it is often the case that software systems belonging to different organizations utilize many software modules that are the same or similar, and/or software modules that involve similar customizations. For example, software systems belonging to different organizations in the same field of operations may involve similar customizations that are related to the field of operations. Thus, despite organization-specific differences in software systems of different organization, it is often the case that users belonging to the different organizations end up running the same, or quite similar, transactions on their respective systems.